Traditional voice networks usually have a hierarchy of switches that are used to route calls from one local exchange to another via transit and potentially international transit switches. Calls are passed from switch to switch, which each makes its own local routing decision based on the telephone number (end address) and also in part on the service state of the TDM link used to reach the next switch. If a link is busy, out of service or indeed if the switch is out of service, the proceeding switch uses alternate routes to bypass the nodes affected by a service congestion or equipment outage.
In networks implementing VoIP technology the call control and the media transport are separated into independent media and session control planes. With the advent of centralised routing servers that can be interrogated by the various network components the session control plane may have a non-hierarchical, flat architecture. For example, in closed networks, i.e. networks where one operator controls the ingress and egress of sessions within their network, the equipment dealing with session ingress or session origination can look up a destination address or telephone number via a central server to determine the primary destination equipment for session egress or session termination as well as a list of alternatives. An example of such a closed network is shown in FIG. 1. The network 8 comprises a number of session control nodes 10A-10D and a centralised routing policy server 12, which can be for example an enum server, a SIP redirect server or a DNS (Domain Name Service). A session setup is performed in several steps and will be explained in relation to FIG. 1. In step 1 an originating end user or originating network 14 sends a session setup request for destination address X to session control edge node 10A, where X may be a telephone number or a name. In step 2 the session control edge node 10 submits a routing request for address X to the centralised routing policy server 12. The server 12 stores a number of static routing policies and in step 3 it returns one or more routing alternatives to the source node 10A; for example 1st Node 10C, 2nd Node 10D. In step 4 the node 10A sends a session setup request to node 10C, the first alternative, and in step 5 the session control edge node 10C forwards the session setup request to the destination end user or destination network 16. In this network 8 there is not direct feedback to a source session control equipment 10A as to whether the destination session control equipment 10 B-D, which has been selected by the centralised routing policy function 12, is available to receive calls. It may have become isolated from the network through transmission faults or be out of service through equipment fault or planned maintenance and therefore unable to respond to any session setup signalling. A session setup message that is sent to such ‘unreachable’ destination equipment in the network will usually be retried a number of times by the source 10A before deciding to try any alternative route provided by the centralised routing policy function 12 or any local default routing policy. However, the elapsed time taken for this to happen can be such that the user 14 abandons the session set up before the source node 10A tries the alternate route. Even if the source node 10A learns to avoid the non-available destination equipment after a series of retries, it has no inherent mechanism to determine when the destination equipment is back in service.
To overcome this, VoIP and Multimedia session control functions 10A-D often send ‘heartbeat’ messages between each other so as to detect when its partner is unreachable and subsequently not available for service. Patent application EP2096794 discloses one such system where a monitored device sends service status information to a monitoring device via SIP messages according to instructions regularly received from the monitoring device. In SIP networks the OPTIONS message is often used between control nodes to bilaterally determine node status. However, bilateral heartbeat messages cause a problem as flat network architectures scale the number of session control nodes. If messages are exchanged bilaterally between n nodes every f seconds then the message rate is (2*n*(n−1))/f=2(n2−n)/f per second. The factor ‘2’ pertains to normal circumstances in which there is the same number of responses as there are heartbeat request messages. Therefore this message rate grows as a square of the nodes within a network, which on a large scale, such as a national or global network, can use significant node processing and network bandwidth, which may be costly and at a premium on remote international nodes. It also causes a significant management problem every time a node is added or permanently removed within the overall network as this network topology change has to be distributed to all other nodes.
Patent application WO2008013649 discloses a system which solves the problem of a call control manager (CCM) not having information about a bearer path within the domain that it controls. Without knowledge of the packet performance of the bearer path, the CCM may establish calls that result in poor voice quality or call setup failure. Therefore nodes in the network under the control of the CCM are configured to collect and communicate network packet performance information in the form of data packets via communication links to the CCM. Because the CCM communicates with multiple network nodes, the CCM may be configured to route calls based on the network performance information, such as available bandwidth, packet delay or packet loss, collected from the network nodes. If the characteristics of the IP path or terminating segment to a terminating trunk is impaired then the CCM can make a decision to use less bandwidth through codec choice or find an alternative terminating trunk with a different ‘terminating segment’ via a different path across the IP network. In the described architecture there is a direct and permanent signalling link between the CCM and a Media Gateway (MG). Hence, WO2008013649 assumes that the CCM controls, and is therefore aware of the status of, terminating trunks (Media Gateways) via direct signalling, which does not economically or practically scale into the very large VoIP networks being developed today both nationally and globally. Further, while WO2008013649 teaches that path performance data can be gathered by CCMs in different networks and shared between these networks, it is silent with respect of the signalling relationship between the session control peers, e.g. CCMs, and a CCM in one network would not know that a CCM in another network has failed.